• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    Dieser Patentantrag betrifft ein Verfahren und eine Vorrichtung zur effizienteren und sichereren Codierung von E-Mails ("Electronic Mail", spezifiziert in den RFCs 2822 und 2821 der Internet Engineering Task Force, www.ietf.org/rfc/rfc2822.txt bzw. www.ietf.org/rfc/rfc2821.txt). Effizienz wird dadurch erreicht, dass eine Vielzahl von Codierungsverfahren, die heute in einer "normalen" E-Mail vorkommen, durch ein einheitliches Codierungsverfahren ersetzt wird. Eine erhöhte Sicherheit wird dadurch erreicht, dass die historisch gewachsene Trennung einer E-Mail in "Header" und "Body" zwar beibehalten, im neuen Codierungsverfahren enthaltene Sicherheitsmechanismen aber auf beide Teile angewandt werden. Als wichtigste Verbesserung der Sicherheit ist hier eine wirksame Methode zur Abwehr von SPAM-Mails zu nennen.This patent application relates to a method and an apparatus for more efficient and secure encoding of e-mails ("Electronic Mail", specified in the RFCs 2822 and 2821 of the Internet Engineering Task Force, www.ietf.org/rfc/rfc2822.txt or www .ietf.org / rfc / rfc2821.txt). Efficiency is achieved by replacing a multitude of coding methods, which today occur in a "normal" e-mail, with a uniform coding method. Increased security is achieved by retaining the historically grown separation of an e-mail in "Header" and "Body", but applying security mechanisms in the new coding procedure to both parts. One of the most important security enhancements is an effective way to ward off spam emails.
    公开号:DE102004011042A1
    申请号:DE102004011042
    申请日:2004-03-06
    公开日:2005-09-29
    发明作者:
    申请人:Schwenk, Jörg, Prof. Dr.；
    IPC主号:G06F17-30
    专利说明:
    [0001] E-Mailist neben dem WWW der wichtigste Dienst im Internet, und mit Abstandder älterevon beiden: Der RFC 822 „STANDARDFOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES" datiert vom 13. August 1982, und dasdarin beschriebene ASCII-basierte Textformat ist auch heute nochdie Grundlage aller im Internet versendeten E-Mails.e-mailis next to the WWW the most important service on the Internet, and by farthe olderof both: The RFC 822 "STANDARDFOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES "dated August 13, 1982, and theASCII-based text format described in it is still todaythe basis of all e-mails sent on the Internet.
    [0002] Schnellstellte sich heraus, dass die Nutzer mit E-Mails mehr übertragenwollen als reinen Text. Man behalf sich zunächst damit, die zu übertragendenBinärdateienvon Hand in ein RFC 822-kompatibles Format zu konvertieren (z.B.uuencode unter UNIX), aber dies war keine befriedigende Lösung. Sowurden im November 1996 die „MultipurposeInternet Mail Extension (MIME, RFC 2045 – 2049) verabschiedet, dieeine plattformunabhängige Übertragungsmethodefür beliebigeDaten im RFC 822-Format festlegten. Die wichtigste Codierungsartfür Binärdaten istdabei base64, mit der eine Expansion der Daten um 33% einhergeht.MIME strukturiert die übertragenenDaten dabei in einer baumartigen Struktur, die mit Hilfe von trennendenZeichenketten („boundary") aufgebaut wird.Fastturned out that users with emails transfer morewant as pure text. At first they made use of it to transfer thembinariesmanually convert to RFC 822 compatible format (e.g.uuencode on UNIX), but this was not a satisfactory solution. SoIn November 1996, the "MultipurposeInternet Mail Extension (MIME, RFC 2045 - 2049) passed, thea platform-independent transfer methodfor anyData specified in RFC 822 format. The most important coding typefor binary datadoing base64, which is accompanied by an expansion of the data by 33%.MIME structures the transferred onesData thereby in a tree-like structure, with the help of separatingStrings ("boundary") is built.
    [0003] Einekonsequente Weiterentwicklung des MIME-Standards stellt Secure MIME(S/MIME, RFCs 2311, 2312, 2630, 2632, 2633, ab März 1998) dar. Hier wird festgelegt,wie MIME-formatierte Daten mit Hilfe moderner kryptographischerMethoden gesichert werden können.Da kryptographische Operationen immer Binärdaten liefern, mussten hierzudie Mailstandards um binäreDatenformate ergänztwerden. Diese basieren letztendlich auf der Datenbeschreibungssprache „AbstractSyntax Notation 1" (ASN.1),die das genaue Gegenteil der MIME-Philosophie verkörpert: einemöglichstkompakte Darstellung der Daten durch bitgenaue Codierung.AConsistent further development of the MIME standard is provided by Secure MIME(S / MIME, RFCs 2311, 2312, 2630, 2632, 2633, from March 1998). Here it is determinedhow MIME-formatted data using modern cryptographicMethods can be secured.Since cryptographic operations always provide binary data, they had tothe mail standards are binaryData formats addedbecome. These are ultimately based on the data description language "AbstractSyntax Notation 1 "(ASN.1),which embodies the exact opposite of the MIME philosophy: onepreferablycompact representation of the data through bit-precise coding.
    [0004] Durchdie stürmischeEntwicklung des WWW verwischten sich die Grenzen zwischen E-Mail und WWW: EinStandard-E-Mail-Client muss heute HTML-codierte Mails mit eingebettetenBildern darstellen und das HTTP-Protokoll sprechen können. Inzwischenbeginnt XML das spezialisiertere HTML abzulösen, und so müssen dieClients auch hier nachrüsten.Bythe stormyDevelopment of the WWW blurred the boundaries between e-mail and WWW: AStandard e-mail client today must have HTML-encoded mails with embeddedDisplay images and speak the HTTP protocol. meanwhileXML begins to replace the more specialized HTML, and so must theClients also retrofit here.
    [0005] Einerster Ansatz zur Transformation von MIME-E-Mails in XML-Daten wurdeim Jahr 2000 von der Firma Mediaone unter dem Namen „eXtensibleMail Transport Protocol (XMTP)" vorgestellt.Das sehr knapp gehaltene Dokument dazu ist heute noch unter http://xml.coverpages.org/xmtp20000508.htmlzu finden. Nach Durchsicht dieses Dokuments muss man zu dem Schlusskommen, dass es sich dabei nur um eine direkte Übersetzung von MIME nach XMLhandelt, die keines der genannten Probleme löst: • Die Strukturder erzeugten XML-Dokumente ist sehr unklar definiert; ein XML Schema,das eine XMTP-Nachricht akzeptiert, wird auch viele falsche XML- Daten akzeptieren.Das in dieser Anmeldung angegebene XML-Schema kann dagegen gültige vonungültigenXMaiL-Nachrichten klar unterscheiden. • Umnur ein Beispiel zu nennen: Das MIME-Konstrukt „boundary" wird in MIME dazu verwendet, eine Baumstrukturim Body der E-Mail zu erzeugen. Da XML-Dokumente immer Baumstruktur haben,kann auf dieses Konstrukt eigentlich verzichtet werden, aber XMTPbehältes bei. • Sicherheitsfragenwerden bei XMTP in keinster Weise angesprochen. A first approach to transforming MIME emails into XML data was presented by Mediaone under the name "eXtensible Mail Transport Protocol (XMTP)" in 2000. The very scarce document is still available at http: / /. /xml.coverpages.org/xmtp20000508.html After reviewing this document, you have to conclude that this is just a direct translation from MIME to XML that does not solve any of the issues mentioned above: • The structure of the generated XML documents is very unclear; An XML schema that accepts an XMTP message will also accept many incorrect XML data. The XML Schema specified in this application, on the other hand, can clearly distinguish valid from invalid XMaiL messages. • Just to name a few examples: The MIME construct "boundary" is used in MIME to create a tree structure in the body of the e-mail, since XML documents always have a tree structure, but this construct can actually be dispensed with, but XMTP keeps it. • Security issues are not addressed in any way with XMTP.
    [0006] Diefür denStand der Technik wichtigsten Internetstandards sind (Request forComments (RFC) der Internet Engineering Task Force (IETF), abrufbarunter http://www.ietf.org/rfc/rfcNNNN.txt): • ProposedStandard RFC 1341 MIME (Multipurpose Internet Mail Extensions),1992 • ProposedStandard RFC 1421 Privacy Enhancement for Internet Electronic Mail,1993 • DraftStandard RFC 1521 MIME (Multipurpose Internet Mail Extensions),1993 • ProposedStandard RFC 2015 MIME Security with Pretty Good Privacy (PGP),1996 • DraftStandard RFC 2045 MIME (Multipurpose Internet Mail Extensions),1996 • InformationalRFC 2311 S/MIME Version 2 Message Specification, 1998 • RFC2557 – MIMEEncapsulation of Aggregate Documents, such as HTML (MHTML) • ProposedStandard RFC 2633 S/MIME Version 3 Message Specification, 1999 • ProposedStandard RFC 2822 Internet Message Format, 2001 The most important Internet standards for the state of the art are (Request for Comments (RFC) of the Internet Engineering Task Force (IETF), available at http://www.ietf.org/rfc/rfcNNNN.txt): • Proposed Standard RFC 1341 MIME (Multipurpose Internet Mail Extensions), 1992 Proposed Standard RFC 1421 Privacy Enhancement for Internet Electronic Mail, 1993 • Draft Standard RFC 1521 MIME (Multipurpose Internet Mail Extensions), 1993 • Proposed Standard RFC 2015 MIME Security with Pretty Good Privacy (PGP), 1996 • Draft Standard RFC 2045 MIME (Multipurpose Internet Mail Extensions), 1996 • Informational RFC 2311 S / MIME Version 2 Message Specification, 1998 • RFC 2557 - MIME Encapsulation of Aggregate Documents, search as HTML (MHTML) • Proposed Standard RFC 2633 S / MIME Version 3 Message Specification, 1999 Proposed Standard RFC 2822 Internet Message Format, 2001
    [0007] Diewichtigsten zu berücksichtigendenXML-Standards sind (herausgegeben vom WWW-Konsortium, www.w3c.org): • XMLBase • XMLSignature • XMLEncryption • Xpath • XMLSchema • XSLund XSLT • XHTML • XMLKey Management The main XML standards to consider are (published by the WWW Consortium, www.w3c.org): • XML Base • XML Signature • XML Encryption • Xpath • XML Schema • XSL and XSLT • XHTML • XML Key Management
    [0008] AlsFazit könnenwir festhalten, dass E-Mail-Clients heute folgende, nicht verwandteDatenformate verarbeiten könnenmuss: • RFC822 (in der aktuellen Version RFC 2822, nur für E-Mail), • MIME(nur fürE-Mail), • S/MIME(Cryptographic Message Syntax, ASN.1-basiert, kompatibel zu PKCS#7und den X.509-PKI-Standards) und • HTML/XML(kompatibel zum WWW). In conclusion, we can state that e-mail clients today must be able to process the following, unrelated data formats: • RFC 822 (in the current version RFC 2822, only for e-mail), • MIME (only for e-mail), • S / MIME (Cryptographic Message Syntax, ASN.1-based, compatible with PKCS # 7 and the X.509 PKI standards) and • HTML / XML (compatible to the WWW).
    [0009] Dadie ersten beiden Datenformate (RFC 822, MIME) in dieser Form nurbei E-Mails vorkommen, und das dritte denkbar inkompatibel zu dendrei anderen ist (und daher völligeigenständigeImplementierungen erfordert), kann es in Zukunft ein Problem mitder Wartung dieses Codes geben.Therethe first two data formats (RFC 822, MIME) in this form onlyoccur in emails, and the third conceivable incompatible with thethree others is (and therefore completelyindependentImplementations requires), there may be a problem with it in the futurethe maintenance of this code.
    [0010] Alsweiterer Aspekt kommt hinzu, dass Firmen in Zukunft verpflichtetsein werden, ihre E-Mail-Geschäftskorrespondenzgeeignet zu archivieren, wie dies auch bei schriftlicher Korrespondenzder Fall ist. Durch das oben aufgezeigte Nebeneinander unterschiedlichsterStrukturen in einer E-Mail bietet sich hier als einzige Möglichkeitdie Speicherung als BLOB (Binary Large OBject) in einer Datenbankan. Dadurch wird die Suche nach bestimmten Kriterien in der gesammeltenE-Mail-Korrespondenz sehr aufwendig.WhenAnother aspect is that companies commit in the futurebe their e-mail business correspondencesuitable for archiving, as with written correspondencethe case is. By the above-mentioned juxtaposition of differentStructures in an e-mail are the only option herestoring as BLOB (Binary Large OBject) in a databaseat. This will search for specific criteria in the collectedE-mail correspondence very expensive.
    [0011] VertraulicheInformationen in E-Mails oder deren Anhängen können mitgelesen werden. DiesesProblem ist bekannt und wird im Prinzip durch die Internet-StandardsS/MIME und OpenPGP gelöstDennoch wird heute auch weiterhin nur ein geringer Anteil der Internet-Mailsverschlüsselt.Dies hat folgende Gründe: • Diefür dieVerarbeitung von S/MIME-Nachrichten verwendeten Algorithmen sindsehr komplex und wenig verbreitet, weil sie auf dem ASN.1-Datenformatbasieren, das von allen sonst im Internet verwendeten Datenformatendenkbar weit entfernt ist. Konsequenterweise findet man in Open-Source-Projektenwie Mozilla (Nachfolger des Netscape Messenger) oder Linux fastkeine S/MIME-Implementierungen,sondern lediglich OpenPGP. • InOpenPGP wird den oben genannten vier Datenformaten ein fünftes hinzugefügt. Auchin OpenPGP werden die binärenErgebnisse kryptographischer Operationen auf spezielle Art und Weisecodiert. Dabei wird aber das Schlüsselmanagement-Problem nichtsauber gelöst,und der Einsatz scheitert einfach daran, dass man den Schlüssel desKommunikationspartners nicht kennt. Confidential information in e-mails or their attachments can be read. This problem is known and is in principle solved by the Internet standards S / MIME and OpenPGP. Nevertheless, today only a small percentage of Internet mails continue to be encrypted. This has the following reasons: • The algorithms used to process S / MIME messages are very complex and not very common because they are based on the ASN.1 data format, which is very far from any other data format used on the Internet. Consequently, in open source projects such as Mozilla (successor to Netscape Messenger) or Linux, there are almost no S / MIME implementations, only OpenPGP. • In OpenPGP, a fifth is added to the above four data formats. Also in OpenPGP the binary results of cryptographic operations are coded in a special way. However, the key management problem is not solved properly, and the mission simply fails because one does not know the key of the communication partner.
    [0012] BeideAnsätzehaben eine gemeinsame Schwäche:Sie berücksichtigendie historisch gewachsene Trennung zwischen E-Mail-Header und E-Mail-Body(RFC 822, RFC 2822), und schützennur letzteren mit kryptographischen Methoden. Dies hat folgendeKonsequenzen: • Absendeadressen (das „FROM:"-Feld im RFC 822-Header)sind kryptographisch nicht gesichert und können ggf. gefälscht werden,ohne dass ein E-Mail-Client dies anzeigt. S/MIME-Clients sollenzwar die Adresse im „FROM:"-Feld mit der Adresseim X.509-Zertifikat vergleichen, es ist jedoch keineswegs sicher,dass alle Clients dies auch tun. Für OpenPGP ist der entsprechendeSachverhalt noch zu klären. • Empfängeradressen(das „TO:"-Feld von RFC 822)sind nicht kryptographisch geschützt(auch nicht durch eine Soll-Anweisung). Sie können für signierte Mails leicht manipuliertwerden. (FürverschlüsselteMails macht dies keinen Sinn, da sie vom geänderten Empfänger janicht gelesen werden können. Both approaches have a common weakness: they take into account the historically grown separation between e-mail header and e-mail body (RFC 822, RFC 2822), and only protect the latter with cryptographic methods. This has the following consequences: • Sender addresses (the "FROM:" field in the RFC 822 header) are not cryptographically secured and can be forged if they are not displayed by an e-mail client, although S / MIME clients should use the address in "FROM : "- Compare the field with the address in the X.509 certificate, but it is by no means certain that all clients will do so. For OpenPGP the corresponding facts still have to be clarified. • Recipient addresses (the "TO:" field of RFC 822) are not cryptographically protected (not even by a target statement) They can easily be manipulated for signed mails (for encrypted mails this makes no sense since they are changed by the modified Receiver can not be read yes.
    [0013] DieseBeobachtungen beeinträchtigenzum einen die Sicherheit normaler E-Mails (die vom Mailserver-Administratorsignierte Mail „Siehaben Ihr Mailvolumen überschritten" könnte mitverändertem „TO:"-Feld auch an andereNutzer weitergeleitet werden, und so für Konfusion sorgen), sie setztaber auch die Wirksamkeit digitaler Signaturen als viel geprieseneMöglichkeitzur Verhinderung von SPAM-Mails außer Kraft: Bei hinreichendgroßerVerbreitung digital signierter E-Mails könnte man SPAM-Mails aussortieren,indem man alle nicht signierten Mails in den Papierkorb wirft. Umdiesen Filter zu überwindenmüssteein SPAM-Anbieter, so die gängigeArgumentation, alle versendeten E-Mails signieren, was ihm einenKostenfaktor in Form enorm gestiegenen Rechenaufwands aufbürden würde. Dieserauch finanziell bezifferbare Mehraufwand pro E-Mail würde SPAMwirtschaftlich unattraktiv machen.These observations, on the one hand, affect the security of normal e-mails (the e-mail signed by the mail server administrator "You have exceeded your mail volume" could also be forwarded to other users with a modified "TO:" field, causing confusion) but also invalidates the effectiveness of digital signatures as a much-praised way to prevent SPAM emails: With sufficiently large spread digitally signed emails could be sorted out SPAM emails by throwing all unsigned emails in the trash. To overcome this filter would have a SPAM provider, according to the common reasoning, all signed e-mails sign, which would incur him a cost in the form of enormously increased computational burden. This also financially quantifiable additional expenditure per E-Mail would make SPAM economically unattractive.
    [0014] Diesist jedoch nicht der Fall, da ein SPAM-Anbieter folgende Alternativenhat: 1. Er besorgt sich für jede Mailingaktion eine neueE-Mail-Adresse (fürwenige Cent) und ein kostenloses E-Mail-Zertifikat. Dann signierter eine Mail, speichert diese ab, schreibt ein kleines Programm,das nur die „TO:"-Zeile austauscht,und versendet die Mails wie gewohnt. 2. Falls der SPAM-Filter auf „NoSPAM"-PKIs (...) beschränkt wurde, kann er eine „gute" Mailadresse zum Signiereneiner E-Mail verwenden, und dann auch das „FROM:"-Feld austauschen. Die Erfolgsrate dieses Vorgehenshängt vonder Anzahl der E-Mail-Clients ab, die nicht korrekt prüfen, undmüssteempirisch ermittelt werden. However, this is not the case since a SPAM provider has the following alternatives: 1. He gets a new email address (for a few cents) and a free e-mail certificate for each mailing campaign. Then he signs an email, saves it, writes a small program that only exchanges the "TO:" line, and sends the mail as usual. 2. If the SPAM filter has been restricted to "NoSPAM" -PKIs (...), it can use a "good" email address to sign an email, and then also swap the "FROM:" field This procedure depends on the number of email clients that are not validating correctly and should be determined empirically.
    [0015] Zeitstempel:Ein wichtiger Nachteil von E-Mail gegenüber normaler Post ist der fehlendeNachweis, wann eine Nachricht abgeschickt oder wann sie angekommenist. Zumindest das ungefähreAbsendedatum wird durch ein halbamtliches Siegel, den Poststempel,quittiert. Im Internet gibt es Zeitstempeldienste, die ähnlicheNachweiskraft besitzen, aber es ist unklar, wie sie in eine E-Mailsicher eingebunden werden sollen.Time stamp:An important disadvantage of e-mail over regular mail is the missing oneProof of when a message was sent or when it arrivedis. At least the approximateDate of despatch is indicated by a semi-official seal, the postmark,acknowledged. On the Internet, there are time stamp services, the similarOwn proof, but it is unclear how they are in an emailshould be securely integrated.
    [0016] Mankann nun versuchen, die oben aufgezeigten Probleme durch Erweiterungder bestehenden E-Mail-Standards zu lösen: Einbeziehung des Headers(oder bestimmter Headerfelder) in die Signatur durch Modifikationvon S/MIME und OpenPGP, Entwicklung von MIME-Datenbanken, Einführung neuerHeaderfelder fürZeitstempel.youcan now try the problems outlined above by extensionto solve the existing e-mail standards: inclusion of the header(or certain header fields) in the signature by modificationfrom S / MIME and OpenPGP, development of MIME databases, introduction of new onesHeader fields forTime stamp.
    [0017] Einsolcher Lösungsansatzwirkt aber leicht anachronistisch in einer Zeit, in der alle Softwarefirmen bestrebtsind, ihre Produkte auf einen einzigen Standard hin auszurichten:XML. (Z.B. basieren in Office 2003 von Microsoft die Datenformatevon Excel und Word bereits auf XML, andere Office-Produkte sollenfolgen.) Die hier vorgeschlagen Lösung, XMaiL genannt, basiertauf der Idee, alle Datenstrukturen einer E-Mail in XML nachzubilden.Die XML Standardsuite bietet dafürheute alle nötigenTeilstandards.Onesuch approachBut it seems a bit anachronistic at a time when all software companies are anxiousare aligning their products to a single standard:XML. (For example, in Microsoft Office 2003, the data formats are basedExcel and Word already intended to XML, other Office productsfollow.) The solution proposed here, called XMaiL, is basedon the idea of replicating all the data structures of an e-mail in XML.The XML standard suite offers for itall necessary todayPart standards.
    [0018] Dazumüssendie Datenstrukturen, die in den einschlägigen Internetstandards beschriebensind, in XML-Datenstrukturen übersetztwerden. Dabei treten verschiedene Problem auf, die anhand der jeweiligen Standardsgelöstwerden müssen,und die hier beispielhaft fürdie jeweiligen Standards beschrieben werden sollen.Tohave tothe data structures described in the relevant Internet standardsare translated into XML data structuresbecome. There are several problems that are based on the respective standardssolvedNeed to become,and here for examplethe respective standards should be described.
    [0019] Diegenaue Umsetzung der ersten Gruppe von Standards in die zweite Gruppekann mit Hilfe von XML Schemas erfolgen. Vereinfachte Versionendieser XML-Schemas werden im Rahmen der Ausführungsbeispiele vorgestellt.TheAccurate implementation of the first group of standards in the second groupcan be done using XML Schemas. Simplified versionsThese XML Schemas are presented within the framework of the exemplary embodiments.
    [0020] DasThema Sicherheit nimmt unter den Beispielen einen breiten Raum ein,da gerade hier großeVerbesserungen möglichsind, die Umsetzung aber auf große Schwierigkeiten stößt.TheSecurity issues are widely used in the examplesbecause there are big onesImprovements possiblebut implementation is facing great difficulties.
    [0021] Anmerkungzur Terminologie: Im Folgenden werden Teile einer E-Mail immer mitden Bezeichnungen aus den jeweiligen IETF-Standards bezeichnet,z.B. mit „Header" (ohne Anführungszeichen)für denHeader einer E-Mail, und mit „TO-Feld" für die Zeiledes E-Mail-Quelltextes,die mit „TO:" beginnt. Bestandteileder XML-Datenstruktur, die nach Maßgabe dieser Erfindungsmeldungaus der E-Mail gebildet wird, sind immer XML-Elemente und werden in spitzen Klammernangegeben, die von den XML-Tags bekannt sind, also z.B. <Header> und <TO>.annotationTerminology: In the following parts of an e-mail are always withdesignates the names from the respective IETF standards,e.g. with "header" (without quotation marks)for theHeader of an e-mail, and with "TO-field" for the linethe e-mail source text,which starts with "TO:"the XML data structure, in accordance with this invention disclosureare formed from the email, are always XML elements and are in angle bracketsspecified by the XML tags, e.g. <Header> and <TO>.
    [0022] DieUnterteilung einer E-Mail nach RFC 822 (bzw. RFC 2822) in Headerund Body kann in XML dadurch nachgebildet werden, dass das Wurzelelement <XMaiL> genau zwei Unterelemente <Header> und <Body> besitzt. Es sind auchandere Aufteilungen möglich,aber die vorgeschlagene Unterteilung macht Sinn, weil in <Header> und <Body> sinnvollerweise völlig verschiedeneUnterelemente vorkommen.TheSubdivision of an e-mail according to RFC 822 (or RFC 2822) into headersand Body can be modeled in XML by the fact that the root element <XMaiL> has exactly two subelements <Header> and <Body>. There are tooother splits possible,but the proposed subdivision makes sense, because in <Header> and <Body> usefully differentSubelements occur.
    [0023] Anmerkung:Diese Aussage wird auch nicht durch die Tatsache widerlegt, dassbestimmte MIME-Header bei einer E-Mail sowohl im Header als auchim Body gleichartige MIME-Felder wie „Content-Type: Multipart/Mixed" auftauchen; diesist lediglich als historisches Relikt zu sehen, das beim Übergangvon einem reinen (ASCII-) Textformat zu einem Multimediaformat unvermeidlichwar.Note: This statement is not contradicted by the fact that certain MIME Hea MIME fields such as "Content-Type: Multipart / Mixed" appear in an e-mail in both the header and the body, this can only be seen as a historical relic, which, when moving from a pure (ASCII) text format to a multimedia format was inevitable.
    [0024] Diefolgende Tabelle gibt die Umsetzung der Beispielnachricht aus AnhangA.1.1 von RFC 822 wieder. Da eine Leerzeile nach RFC 2822 die beidenTeile Header und Body der E-Mail trennt, wurde in der Tabelle aufeine zeilenweise Zuordnung der Bestandteile verzichtet. (Dies wirdaber in den folgenden, komplexeren Beispielen getan.)
    [0025] Dasobige Beispiel ist eine direkte Übertragungder E-Mail-Struktur nach RFC 2822 in eine XML-Struktur. Im Gegensatzzu dem im Stand der Technik beschriebenen Verfahren wird hier aberdie Unterteilung in Header und Body beibehalten, da diese konstitutivfür alle(auch die erweiterten) E-Mail-Formate ist. Die einzige Abweichungvon diesem Prinzip ist die weitergehende Kapselung des eigentlichenNachrichtentextes in die XML-Element <Text> undPlain>. Dies wurdeim Hinblick auf die Erweiterung auf MIME-formatierte Mails gemacht,da so einfach strukturierte E-Maisl wie in diesem Beispiel im heutigenInternet fast nicht mehr versendet werden.TheThe above example is a direct transferthe e-mail structure according to RFC 2822 into an XML structure. In contrastbut the method described in the prior art is here butmaintain the subdivision into headers and body as these are constitutivefor all(also the extended) E-Mail formats is. The only deviationfrom this principle is the further encapsulation of the actualMessage text in the XML element <text> andPlain>. That waswith regard to the extension made to MIME-formatted mail,because so easily structured e-corn as in this example in todayInternet almost no longer be shipped.
    [0026] Beidem angeführtenBeispiel ist zu beachten, dass es durchaus noch sinnvolle Variantenbei der Umsetzung gibt. So könntenz.B. die Schachtelung des ASCII-Textes in die XML-Elemente <Text> und <Plain> auch durch ein eizigesXML-Element <TextPlain> ersetzt werden, dasdann den Text enthalten würde.atthe citedExample should be noted that there are still reasonable optionsin the implementation there. So coulde.g. the nesting of the ASCII text in the XML elements <Text> and <Plain> also by a singleXML element <TextPlain> to be replacedthen would contain the text.
    [0027] Eineinfaches XML-Schema fürdieses Beispiel könntewie folgt aussehen.
    [0028] Durchdas in 2 wiedergegebene XML-Schemawird auch klar, warum es sinnvoll ist, die Unterteilung in Headerund Body beizubehalten: • Die Unterelemente des <Header>-Elements haben keinevorgegebene Reihenfolge; dies entspricht der Praxis in E-Mails nachRFC 2822. • Indas <Header>-Element können weitere,proprietäreUnterelemente eingefügtwerden, in 2 angedeutet durch dreiPunkte („..."). Dies entsprichtder gängigenPraxis, Informationen überden sendenden E-Mail-Client einzufügen (siehe nächstes Beispiel). • EinzelneUnterelemente des <Header>-Elements können mehrfachauftreten; auch dies entspricht der Praxis, dass E-Mail-Gatewaysder E-Mail auf ihrem Weg vom Sender zum Empfänger solche „Received:"-Einträge hinzufügen. • ImGegensatz dazu hat der Body einer Nachricht eine klar definierteStruktur, die bei dieser einfachen E-Mail sehr einfach strukturiertist, durch die Einbindung von MIME-Mechanismen aber sehr flexibelwird. Through the in 2 Also, it becomes clear why it makes sense to keep the subdivision into header and body: • The subelements of the <Header> element do not have a given order; this corresponds to the practice in emails according to RFC 2822. • Additional, proprietary subelements can be inserted into the <Header> element, in 2 indicated by three dots ("..."), which is the common practice of inserting information about the sending e-mail client (see next example). • Individual subelements of the <Header> element can occur multiple times; Again, this is the practice of e-mail gateways adding such "Received:" entries to the e-mail on its way from the sender to the recipient. • In contrast, the body of a message has a well-defined structure, which is very simple in this simple e-mail, but which becomes very flexible through the inclusion of MIME mechanisms.
    [0029] Ausführungsbeispiel2: MIME-formatierte E-Mail Bei der Umsetzung der MIME-Struktur einerE-Mail, die in XML möglichtidentisch nachgebildet werden soll, ergeben sich Schwierigkeiten,deren Lösungwie folgt beschrieben werden kann: • Für jedenmöglichenWert des MIME-Attributs Content-Type werden zwei (bzw. ein) neuesXML-Element gleichen oder ähnlichenNamens eingeführt: – Alternative1: Die Kombination Type/Subtype des MIME-Attributs wird in zweiXML-Elemente <Typ> und <Subtyp> übersetzt, wobei <Subtyp> ein Unterelement von <Typ> sein muss. (Beispiel: „Content-Type: Multipart/Mixed" wird zu <Multipart><Mixed> ... </Mixed></Multipart>.) – Alternative 2: Die KombinationType/Subtype des MIME-Attributs wird in ein XML-Element <TypSubtyp> übersetzt. (Beispiel: „Content-Type:Multipart/Mixed" wirdzu <MultipartMixed> ... </MultipartMixed >.) – Content-Type:multipart/mixed der Tag <MultipartMixed>) • 1.Gliederungsebene: Das <Body>-Element der XMaiLenthältnur ein direktes Unterelement. Dieses Element entspricht dem MIME „Content-Type" im Header der E-Mail.(Alternativ wärees auch möglich,dass der MIME-Content-Type des Body der E-Mail als Attribut des <Body>-Tags gespeichert wird,oder dass es kein <Body>-Element gibt, sondernnur ein Element, das dem MIME-Typ des E-Mail-Body entspricht. Weitere Alternativensind denkbar, ändernden Gesamtansatz aber nicht.) Example 2: MIME-Formatted E-Mail When implementing the MIME structure of an e-mail, which should be simulated identically in XML, difficulties arise, the solution of which can be described as follows: • For each possible value of the Content-Type MIME attribute, two (or one) new XML element of the same or similar name are introduced: - Alternative 1: The Type / Subtype combination of the MIME attribute is written in two XML elements <type > and <subtype>, where <subtype> must be a subelement of <type>. (Example: "Content-Type: Multipart / Mixed" becomes <Multipart><Mixed> ... </ Mixed></Multipart>.) - Alternative 2: The Type / Subtype combination of the MIME attribute becomes XML -Element <type subtype> translated (example: "Content-Type: Multipart / Mixed" becomes <MultipartMixed> ... </ MultipartMixed>.) - Content-Type: multipart / mixed tag <MultipartMixed>) • 1. Outline level: The <Body> element of XMaiL contains only one direct subelement. This element corresponds to the MIME "Content-Type" in the header of the e-mail (Alternatively, it is also possible that the MIME content-type of the body of the e-mail is stored as an attribute of the <Body> tag) there is no <Body> element, just an element that matches the MIME type of the email body, but other alternatives are possible but do not change the overall approach.)
    [0030] Anmerkung:Das einige MIME-Attribute wie z.B. „Content-Type" und „Transfer-Encoding" bei MIME-E-Mailssowohl (einmal) im Header als auch (ggf. mehrmals) im Body einerE-Mail auftauchen, hat historische Gründe: Hätte ein solches Attribut imHeader gefehlt, so hätteder E-Mail-Client den gesamten Body der Nachricht als reinen Textinterpretiert. • Weitere Gliederungsebenen:Je nach Art des Elements kann dieses ein oder mehrere Nachfolgeelement enthalten.Mehr als ein Nachfolgeelement ist dabei nur bei Elementen vom Typ <Multipart><XXX> (bzw. <MultipartXXX>) möglich. • Diegenaue Umsetzung muss durch XML Schemata beschrieben werden, diesich so weit wie möglichan den entsprechenden MIME-Standards orientieren. Ein noch unvollständiges Beispieldazu ist in 4 angegeben. Note: Some MIME attributes such as "Content-Type" and "Transfer-Encoding" for MIME emails appear both (once) in the header and (possibly several times) in the body of an email for historical reasons : If such an attribute had been missing in the header, the e-mail client would have interpreted the entire body of the message as plain text. • Further outline levels: Depending on the type of element, this may contain one or more successor elements. More than one successor element is only possible with elements of the type <Multipart><XXX> (or <MultipartXXX>). • The exact implementation must be described by XML schemas, which are based as far as possible on the corresponding MIME standards. An incomplete example of this is in 4 specified.
    [0031] Inder folgenden 3 erden der (gekürzte) Quelltexteiner Originalmail (mit geändertenMailadressen) im MIME-Quelltextformat, und parallel dazu ihre Umsetzungin das XMaiL-Format, wiedergegeben.
    [0032] In 3 wurde die Variante gewählt, Typund Subtyp eines MIME-Elements in einem XML-Element zusammenzufassen.Das folgende, noch unvollständigeXML-Schema gibtdagegen die Variante wieder, Typ und Subtyp in zwei getrennte, aberverschachtelte XML-Elemente zu übersetzen.In 3 The variant was chosen to combine the type and subtype of a MIME element in an XML element. The following incomplete XML schema, on the other hand, shows the variant of translating type and subtype into two separate but nested XML elements.
    [0033] Gegebensei der folgende (gekürzte)Quelltext einer Originalmail im S/MIME-Format, und parallel dazu dieUmsetzung in das XMaiL-Format. Die grau hinterlegten Felder im S/MIME-Formatsind in ASN.1 codiert und deshalb im ASCII-Quelltext der E-Mailnicht erkennbar (sie sind dort base64-codiert).givenbe the following (shortened)Source text of an original email in S / MIME format, and parallel to thisImplementation in the XMaiL format. The gray fields in S / MIME formatare encoded in ASN.1 and therefore in the ASCII source code of the e-mailnot recognizable (they are base64 coded there).
    [0034] Gegebensei der folgende (gekürzte)Quelltext einer Originalmail im „clear-signed" S/MIME-Format, undparallel dazu die Umsetzung in das XMaiL-Format. Das „opaque-signed-Format istggf. mit dem Aufkommen von XML überholt.Die grau hinterlegten Felder im S/MIME-Format sind in ASN.1 codiertund deshalb im ASCII-Quelltext der E-Mail nicht erkennbar (sie sind dortbase64-codiert).givenbe the following (shortened)Source text of an original email in "clear-signed" S / MIME format, andin parallel, the implementation in the XMaiL format. The "opaque-signed" format ispossibly outdated with the advent of XML.The gray fields in S / MIME format are encoded in ASN.1and therefore not recognizable in the ASCII source code of the e-mail (they are therebase64 encoded).
    [0035] Anmerkungenzu Ausführungsbeispiel4: • Diebeiden XML-Elemente, die sich im XMaiL-Beispiel in einem gestricheltenRahmen befinden, verdeutlichen die neuen Sicherheitsfeatures vonXMaiL: Das <To> und das <From>-Element des <Header>-Elements können hier,im Gegensatz zu S/MIME oder OpenPGP, in die Signatur mit einbezogenwerden. • Alsneues Feature bietet XMaiL die Möglichkeit,durch eine Spezifikation in XPath anzugeben, welche Elemente signiertwerden und, welche verschlüsseltwerden sollen. Der dazu benötigteXPath-Ausdruck kann ggf. in einem E-Mail-Client interaktiv vom Nutzer festgelegtwerden. • ImZuge der weiteren Anpassung aller Datenstrukturen an XML bietetes sich auch an, X.509-Zertifikate in XML nachzubilden. Alle nötigen Konstruktestellt XML bereit. Comments on exemplary embodiment 4: • The two XML elements, which are shown in a dashed frame in the XMaiL example, illustrate the new security features of XMaiL: The <To> and <From> elements of the <Header> element can be used here, in contrast to S / MIME or OpenPGP to include in the signature. • As a new feature, XMaiL offers the possibility of specifying in XPath which elements are to be signed and which ones are to be encrypted. If necessary, the XPath expression required for this purpose can be set interactively by the user in an e-mail client. • In the course of further adaptation of all data structures to XML, it is also possible to emulate X.509 certificates in XML. All necessary constructs are provided by XML.
    [0036] DasProblem der SPAM-Mails kann mit der vorliegenden Erfindung wie folgtgelöstwerden: • JederHersteller von XMaiL-Clients integriert ein Standard-Client-Zertifikat(und den dazugehörigenprivaten Schlüssel)in das Programm, das nichts anderes zertifiziert, als dass bestimmteTeile einer E-Mail digital signiert wurden. Für diese Zwecke reicht ein Zertifikatweltweit aus, oder der Softwarehersteller könnte jedes Build der Softwaremit einem anderen Zertifikat versehen. Wichtig ist, dass diese Zertifikatemit der Software ausgeliefert werden können, und keine Konfigurationsarbeitenvon Seiten des Nutzers erforderlich sind. Installiert der Nutzerspäterein eigenes E-Mail-Zertifikat,so wird natürlichdieses anstelle des Standardzertifikats verwendet. • JederXMaiL-Client signiert standardmäßig mitdiesem Zertifikat das <From>, das <To> und das <Body>-Element jeder E-Mail.Die Signatur wird als „EnvelopedSignature" dem Header-Elementhinzugefügt. Alternativdazu kann sie auch dem Body-Element hinzugefügt werden, das dann allerdingsentsprechend modifiziert werden muss; in diesem Fall kann auch nichtdas gesamte <Body>-Element signiert werden, sondernnur die Elemente ausschließlichdes Signaturelements. • Ebenfallsstandardmäßig istein XMaiL-Filter aktiviert, der alle E-Mails ohne Signatur, mitungültigerSignatur, oder alle E-Mail mit überlangem <To>-Element, in den SPAM-Ordnerwegsortiert. • DemSpam-Mailer werden so Kosten aufgebürdet, da er für jede Gruppevon Adressaten (ungefährzwischen 1 und 30 Empfängern,je nach erlaubter Größe des <To>-Elements) eine digitaleSignatur erstellen muss. Durch Vergrößern der Schlüssellänge in denZertifikaten, und durch Verkürzendes <To>-Elements, kann mandiesen Kostenfaktor skalieren. Der Spam-Mailer kann auch keine fremdenE-Mail-Verteilerlisten mehrbenutzen, da hier das <To>-Element verändert undso die Signatur ungültigwird. • Mitdiesem Verfahren kann man auch den E-Mail-Missbrauch innerhalb vonUnternehmen Herr werden: Der Mitarbeiter, der eine E-Mail an alle20.000 anderen Mitarbeiter sendet, muss dann halt für den Restdes Tages auf seinen Computer verzichten. The problem of spam emails can be solved with the present invention as follows: • Each manufacturer of XMaiL clients integrates a standard client certificate (and associated private key) into the program that certifies nothing other than digitally signing certain portions of an email. For this purpose, a certificate is sufficient worldwide, or the software manufacturer could provide each build of the software with a different certificate. It is important that these certificates can be delivered with the software, and no configuration work by the user is required. If the user later installs his own e-mail certificate, this will of course be used instead of the standard certificate. • By default, each XMaiL client uses this certificate to sign the <From>, <To>, and <Body> elements of each e-mail. The signature is added to the header element as an "Enveloped Signature." Alternatively, it can be added to the body element, but it must be modified accordingly, in which case the entire <Body> element can not be signed. but only the elements excluding the signature element. • By default, an XMaiL filter is also activated, which sorts all e-mails without a signature, with an invalid signature, or all e-mail with an excess <To> element, into the SPAM folder. • The spam mailer will be charged as it creates a digital signature for each group of addressees (approximately between 1 and 30 recipients, depending on the size of the <To> element allowed) got to. By increasing the key length in the certificates, and shortening the <To> element, you can scale this cost factor. The spam mailer can also no longer use external e-mail distribution lists, as this changes the <To> element and invalidates the signature. • This process can also be used to deal with e-mail abuse within companies: The employee who sends an e-mail to all 20,000 other employees then has to give up his computer for the rest of the day.
    [0037] Eineweitere Methode zur Lösungdes SPAM-Problems, die gegenüberder vorher genannten den Vorteil hat, dass sie schnell (d.h. ohnegroßenRechenaufwand), und auch in Mailservern überprüft werden kann, lässt sichwie folgt beschreiben: • Ein wichtiges Element derE-Mail (z.B. das „TO"-Feld oder eine Kombinationaus diesem und anderen Feldern wird ausgewählt. Diese Felder müssen dieVoraussetzungen erfüllen,dass sie in jeder E-Mail andere Werte annehmen, und dass sie während desTransports nicht verändertwerden. • Über dieseFelder wird eine erste (normale) Prüfsumme gebildet, die eine bestimmteBitlänge,z.B. n Bit, haben soll. • DiesePrüfsumme,oder ein anderer geeigneter Wert, wird nun als Teil der Eingabeeiner kryptographischen Einwegfunktion, z.B. einer Hashfunktionwie MDS oder SHA-1, verwendet. Der E-Mail-Client des Senders stehtnun vor der Aufgabe, eine Ergänzungzu dieser Prüfsummezu finden, die zusammen mit der Prüfsumme wieder die Prüfsumme alsErgebnis liefert. Als Formel: f(P,D)=P, wobei f die kryptographische Einwegfunktiondarstellt, P die Prüfsumme,und D den ergänzendenDatensatz. ÄhnlicheVerfahren wurden zur Abwehr von Denial-of-Service-Agriffen als „cryptographicclient puzzles) bezeichnet. Im Gegensatz zu diesen Verfahren istes hier wichtig, ein so genanntes „salt" (in vorliegenden Beispiel die Prüfsumme P,die in die Berechnung des Funktionswertes f(P,D) einfließt) hinzuzunehmen,um kryptographische Angriffe auf Basis des Geburtstagsparadoxons(„birthdayattacks") zu verhindern. • DiesesVerfahren kann auch auf E-Mails angewandt werden, die nicht in dasXMaiL-Format konvertiert wurden,und mit anderen als den genannten Datensätzen. Another method for solving the SPAM problem, which has the advantage over the previous one that it can be checked quickly (ie without much computation effort), and also in mail servers, can be described as follows: • An important element of the e-mail (eg the "To" field or a combination of this and other fields is selected.) These fields must meet the requirements that they take different values in each e-mail and that they are used during the e-mail Transports can not be changed. • These fields form a first (normal) checksum, which should have a specific bit length, eg n bits. • This checksum, or other appropriate value, is now used as part of the input of a one-way cryptographic function, such as a hash function such as MDS or SHA-1. The e-mail client of the sender is now faced with the task of finding a supplement to this checksum, which returns the checksum together with the checksum as the result. As a formula: f (P, D) = P, where f represents the one-way cryptographic function, P the checksum, and D the supplementary data set. Similar methods have been referred to as "cryptographic client puzzles" to defend against denial-of-service attacks. In contrast to these methods, it is important here to add a so-called "salt" (in the present example the checksum P, which is included in the calculation of the function value f (P, D)) in order to generate cryptographic attacks based on the birthday paradox ("birthday attacks "). • This procedure can also be applied to e-mails that have not been converted to the XMaiL format and to records other than those named.
    [0038] Beieinem so überausalten, populärenund auf hunderte Millionen Client-Rechner verteilten Dienst wie E-Mailstellt sich zwangsläufigdie Frage nach Übergangsszenarien:Wie kann ein neues Datenformat eingeführt werden, ohne die Funktionsweisedes alten zu beeinträchtigen atone so overwhelmingold, popularand service distributed to hundreds of millions of client computers, such as e-mailinevitably arisesthe question about transitional scenarios:How can a new data format be introduced without the functionalityto affect the old one
    [0039] DienatürlicheLösungbesteht darin, beide Datenformate so lange wie möglich nebeneinander bestehenzu lassen. Folgender Ablauf wäredenkbar: 1. In der ersten Phase wird XMaiLnur als Archivierungsformat fürE-Mails angewendet. Dazu wird ein Konvertierungsprogramm eingesetzt,dass eine Standard-E-Mail nach XMaiL konvertiert. Dieses Konvertierungsprogrammmuss auch in umgekehrter Richtung funktionieren, d.h. die ursprünglicheE-Mail muss wieder hergestellt werden können. Die XMaiLs können dannin einer XML-Datenbankbequem archiviert werden. 2. In einer zweiten Phase könnenUnternehmen dazu übergehen,den internen E-Mail-Verkehrauf XMaiL umzustellen. Die Anbindung an den Internet-Dienst E-Mail bleibt dabei(im Gegensatz zu alten proprietären Lösungen wieLotus Notes Mail) voll erhalten, da beide Formate ineinander umgewandeltwerden können. UnternehmensinterneSicherheitspolicies könnendabei voll umgesetzt werden, z.B. die Regel, dass intern nur signierteXMaiLs in Umlauf sind (die von Virenschutzsoftware gescannt werdenkönnen),und eine Verschlüsselung(durch einen XPath-Ausdruck spezifiziert) erst im Konvertierungsgatewaybeim Übergangins Internet angewandt wird. 3. Aufgrund des geringen Mehraufwands an Programmcode (die XML-Standardsmüssenvon zukünftigen E-Mail-Clientsalle unterstütztwerden) werden in der dritten Phase alle gängigen E-Mail-Clients XMaiL-Unterstützung anbieten.Zu diesem Zeitpunkt ist eine Einführung möglich. The natural solution is to let both data formats coexist as long as possible. The following process would be conceivable: 1. In the first phase, XMaiL will only be used as an e-mail archiving format. For this purpose, a conversion program is used that converts a standard e-mail to XMaiL. This conversion program must also work in the opposite direction, ie the original e-mail must be able to be restored. The XMaiLs can then be conveniently archived in an XML database. 2. In a second phase, companies can switch to internal email traffic on XMaiL. The connection to the Internet service E-Mail remains fully preserved (as opposed to old proprietary solutions such as Lotus Notes Mail), since both formats can be converted into each other. In-house security policies can be fully implemented, eg the rule that internally only signed XMalls are in circulation (which can be scanned by anti-virus software), and encryption (specified by an XPath expression) is only applied in the conversion gateway during the transition to the Internet. 3. Due to the low overhead of program code (the XML standards must all be supported by future email clients), in the third phase, all major email clients will offer XMaiL support. At this time, an introduction is possible.
    [0040] Zweiweitere Anmerkungen zum Thema Übergangsszenarien: 1. Das SMTP-Protokoll zum Senden und Empfangenvon E-Mails muss nicht notwendigerweise an XMaiL angepasst werden:Ein Client kann die fürSMTP benötigtenDaten aus dem <Header>-Element der XMaiL extrahierenund an das SMTP-Gateway senden. Dieser RFC 822-Header kann „on thefly" immer danngeneriert werden, wenn ein XMaiL-fähiges Gateway auf ein Legacy-Gatewaytrifft. Beim Übergangvon einem Legacy-Gateway zu einem XMaiL-fähigen Gateway muss die neuhinzugekommene Information des RFC822-Header im <Header>-Element ergänzt werden. Die gesamt XMaiLwird von Legacy-Gatewaysals Body einer RFC822-E-Mail behandelt. 2. Währendder Übergangphasestellt das Senden von RFC822-Header plus <Header>-Element im Body eine Lösung für nichtXMaiL-fähigeClients dar; der Client kann wahlweise das eine oder andere verwenden,das <Header>-Element wird dannim Body aber nicht angezeigt (z.B. <Header style="invisible"> o.ä.). Two more notes on transition scenarios: 1. The SMTP protocol for sending and receiving emails does not necessarily have to be adapted to XMaiL: A client can extract the data required for SMTP from the <Header> element of XMaiL and send it to the SMTP gateway. This RFC 822 header can be generated "on the fly" whenever an XMaiL-capable gateway encounters a legacy gateway.When moving from a legacy gateway to an XMaiL-capable gateway, the newly added information of the RFC822- The entire XMaiL is handled by legacy gateways as the body of an RFC822 e-mail. 2. During the transition phase, the sending of RFC822 headers plus <Header> element stops in the body a solution for non-XMaiL-enabled clients; the client can optionally use one or the other, but the <Header> element will not be displayed in the body (eg <Header style = "invisible"> or similar).
    权利要求:
    Claims (32)
    [1]
    Verfahren zur Abbildung von Internet-E-Mailsin ein reines XML-Format [XMaiL], dadurch gekennzeichnet, • dass nebender reinen MIME-Struktur auch alle anderen, in eine E-Mail eingebettetenDatenformate wie S/MIME, CMS/PKCS#7, HTML, XML, usw. in passendeXML-Datenformate überführt werden, • dass dieresultierende XML-Struktur [XMaiL] möglichst genau die Strukturder Internet-Mail widerspiegelt, wobei insbesondere darauf zu achtenist, dass diese Struktur mit Hilfe von XML Schemas zu validierenist.Method for mapping Internet e-mails into a pure XML format [XMaiL], characterized in that • in addition to the pure MIME structure, all other data formats embedded in an e-mail, such as S / MIME, CMS / PKCS # 7, HTML, XML, etc. are converted into suitable XML data formats, • that the resulting XML structure [XMaiL] reflects as closely as possible the structure of the Internet Mail, whereby in particular it must be ensured that this structure with the help of XML Is to validate schemas.
    [2]
    Verfahren nach Anspruch 1, dadurch gekennzeichnet,dass die resultierende XML-Struktur[XMaiL] um Konstrukte aus den Standards XML-Signatur und XML-Verschlüsselungbereichert werden, um die Sicherheit zu verbessern.Method according to claim 1, characterized in thatthat the resulting XML structure[XMaiL] to constructs from the standards XML-Signature and XML-Encryptionenriched to improve safety.
    [3]
    Verfahren nach Anspruch 1, dadurch gekennzeichnet,dass die Unterteilung einer Internet-Mail in Header und Body (RFC822) dadurch berücksichtigtwird, dass es in der XML-Struktur genau zwei Nachfolgeelemente <Header> und <Body> des Wurzelelementsgibt, die diese Struktur widerspiegeln.Method according to claim 1, characterized in thatthat subdivision of an Internet Mail into Header and Body (RFC822)it will be that there are exactly two successor elements <Header> and <Body> of the root element in the XML structurethat reflect this structure.
    [4]
    Verfahren nach Anspruch 3, dadurch gekennzeichnet,dass die Unterelemente des <Header>-Elements nicht inihrer Reihenfolge festgelegt sind.Method according to claim 3, characterizedthat the subelements of the <Header> element are not intheir order.
    [5]
    Verfahren nach Anspruch 1, dadurch gekennzeichnet,dass die einzelnen MIME-Datentypenin XML-Elemente überführt werden,die ihre Struktur erhalten.Method according to claim 1, characterized in thatthat the individual MIME data typesinto XML elements,who receive their structure.
    [6]
    Verfahren nach Anspruch 5, dadurch gekennzeichnet,dass fürjede Kombination von MIME-Typ und -Subtyp ein eigenes XML-Elementdefiniert wird.Method according to claim 5, characterized in thatthat forEach combination of MIME type and subtype has its own XML elementis defined.
    [7]
    Verfahren nach Anspruch 5, dadurch gekennzeichnet,dass fürjeden MIME-Typ ein eigenes XML-Element definiert wird, und dassfür jedenMIME-Subtyp ein eigenes Element definiert wird.Method according to claim 5, characterized in thatthat foreach MIME type is defined its own XML element, and thatfor eachMIME subtype is defined as a separate element.
    [8]
    Verfahren nach Anspruch 5 und einem der beiden Ansprüche 6 oder7, dadurch gekennzeichnet, dass die Struktur der Multipart-Datentypendes MIME-Standards in den entsprechenden XML-Elementen erhalten bleibt,insbesondere • dassdie Unterelemente des XML-Elements oder der Kombination von XML-Elementen, die denTyp Multipart/Mixed repräsentieren,in der vorgegebenen Ordnung dargestellt werden, • dass dieUnterelemente des XML-Elements oder der Kombination von XML-Elementen, die denTyp Multipart/Parallel repräsentieren,in beliebiger Ordnung dargestellt werden, • dass von den Unterelementendes XML-Elements oder der Kombination von XML-Elementen, die denTyp Multipart/Alternative repräsentieren,genau eines dargestellt wird, • dass das XML-Element oderder Kombination von XML-Elementen, die den Typ Multipart/Signedrepräsentieren,genau zwei Nachfolgeelemente hat, von denen eines ein Element vomTyp XML-Signatur ist, das wiederum ein einziges <Reference>-Element enthält, das das andere Nachfolgeelementreferenziert.A method according to claim 5 and one of the two claims 6 or7, characterized in that the structure of the multipart data typesthe MIME standard is preserved in the corresponding XML elements,especially• thatthe subelements of the XML element or the combination of XML elements containing theRepresent type Multipart / Mixed,be presented in the given order,• that theSubelements of the XML element or combination of XML elements containing theRepresent type Multipart / Parallel,be represented in any order,• that of the subelementsthe XML element or the combination of XML elements containing theType multipart / alternative represent,exactly one is shown• that the XML element orthe combination of XML elements that are of type Multipart / Signedrepresent,has exactly two successor elements, one of which is an element ofType is XML signature, which in turn contains a single <Reference> element, which is the other successor elementreferenced.
    [9]
    Verfahren nach den Ansprüchen 1 und 5, dadurch gekennzeichnet,dass die MIME-Datentypen,die intern nach den Standards CMS bzw. PKCS#7 aufgebaut sind, soin XML-Elemente, die in den Standards XML-Signatur und XML-Verschlüsselungdefiniert sind, überführt werden,dass ihre Struktur erhalten bleibt.Process according to Claims 1 and 5, characterizedthat the MIME data types,which are built internally according to the standards CMS or PKCS # 7, soin XML elements included in the standards XML Signature and XML Encryptionare defined, transferred,that their structure is preserved.
    [10]
    Verfahren nach den Ansprüchen 1, 5 und 9, dadurch gekennzeichnet, • dass diein den Zertifikaten, die nach dem X.509-Standard gebildet und inE-Mails mit Hilfeder Standards S/MIME und CMS/PKCS#7 eingebettet werden, enthaltenenInformationen in Strukturen der XML-Standards XML-Signatur und XML-Schlüsselmangementeingebettet werden, • oderdass die Struktur eines X.509-Zertifikats vollständig in einen XML-Datensatz überführt wird,der Elemente aus dem Standard XML-Signatur verwendet.Process according to claims 1, 5 and 9, characterized• that thein the certificates, which are formed according to the X.509 standard and inEmails with helpembedded in the standards S / MIME and CMS / PKCS # 7Information in Structures of the XML Standards XML Signature and XML Key Managementbe embedded• orthat the structure of an X.509 certificate is completely transferred to an XML record,the elements used by the standard XML signature.
    [11]
    Verfahren nach den Ansprüchen 1 und 5, dadurch gekennzeichnet,dass die MIME-Datentypen,die intern nach dem Standard OpenPGP aufgebaut sind, so in XML-Elemente, die inden Standards XML-Signatur und XML-Verschlüsselung definiert sind, überführt werden,dass ihre Struktur erhalten bleibt.Process according to Claims 1 and 5, characterizedthat the MIME data types,which are built internally according to the standard OpenPGP, so in XML elements that are inthe standards XML signature and XML encryption are defined to be transferred,that their structure is preserved.
    [12]
    Verfahren nach einem der Ansprüche 2 bis 11, dadurch gekennzeichnet,dass beliebige XML-Elemente der XML-Struktur [XMaiL] mit Hilfe vonKonstrukten aus dem Bereich der Standards XML-Signatur und XML-Verschlüsselungabgesichert werden.Method according to one of claims 2 to 11, characterizedthat any XML elements of the XML structure [XMaiL] usingConstructs in the field of standards XML signature and XML encryptionbe secured.
    [13]
    Verfahren nach Anspruch 12, dadurch gekennzeichnet,dass das <FROM>-Element von [XMaiL]mit in die Signatur einfließt.Method according to claim 12, characterized in thatthat the <FROM> element of [XMaiL]with flows into the signature.
    [14]
    Verfahren nach Anspruch 12, dadurch gekennzeichnet,dass das <TO>-Element von [XMaiL]mit in die Signatur einfließt.Method according to claim 12, characterized in thatthat the <TO> element of [XMaiL]with flows into the signature.
    [15]
    Verfahren nach Anspruch 14, dadurch gekennzeichnet,dass das <TO>-Element von [XMaiL]in seiner Längebeschränktist.Method according to claim 14, characterized in thatthat the <TO> element of [XMaiL]in its lengthlimitedis.
    [16]
    Verfahren nach den Ansprüchen 13 bis 15, dadurch gekennzeichnet,dass in der XML-Struktur [XMaiL] die Elemente <FROM> und <TO> und mindestens nochein weiteres Unterelement aus dem <Body>-Element oder diesesselbst signiert ist.Process according to claims 13 to 15, characterizedthat in the XML structure [XMaiL] the elements <FROM> and <TO> and at least one moreanother subelement from the <Body> element or this oneself-signed.
    [17]
    Verfahren nach Anspruch 16, dadurch gekennzeichnet,dass zum Signieren nicht ein individueller privater Schlüssel verwendetwird, sondern ein Schlüssel,der zusammen mit dem jeweiligen E-Mail-Client ausgeliefert wirdund von der Herstellerfirma des E-Mail-Clients auf geeignete Artund Weise als authentisch gekennzeichnet wird, z.B. durch signierendes zugehörigen öffentlichenSchlüsselsin einer Public-Key-Infrastruktur.Method according to claim 16, characterized in thatthat does not use an individual private key for signingbecomes, but a keywhich is delivered together with the respective e-mail clientand by the manufacturer of the e-mail client in an appropriate mannerand is marked as authentic, e.g. sign byof the associated publickeyin a public-key infrastructure.
    [18]
    Verfahren nach Anspruch 12, dadurch gekennzeichnet,dass ein ggf. vorhandener Zeitstempel als XML-Element eingebundenwird und mit in die Signatur einfließt.Method according to claim 12, characterized in thatthat a possibly existing time stamp is included as an XML elementand is included in the signature.
    [19]
    Verfahren nach Anspruch 12, dadurch gekennzeichnet,dass ein neues Element in die XML-Struktur [XMaiL] mit aufgenommenwird, die das Urbild eines wichtigen Elements aus der XML-Struktur[XMaiL] unter einer kryptographischen Einwegfunktion erhält.Method according to claim 12, characterized in thatthat a new element was included in the XML structure [XMaiL]being the prototype of an important element from the XML structure[XMaiL] under a one-way cryptographic function.
    [20]
    Verfahren nach Anspruch 19, dadurch gekennzeichnet,dass dieses Verfahren auch auf E-Mails im heute üblichen Internet-Mailformatangewandt wird.Method according to claim 19, characterizedthat this procedure also applies to e-mails in today's standard Internet mail formatis applied.
    [21]
    Verfahren und Endgerät nach den Ansprüchen 1 bis11, dadurch gekennzeichnet, dass der Quelltext einer gegebenen E-Mailnach RFC 2822 in eine XML-Struktur [XMaiL] umgewandelt und das Ergebnisausgegeben wird.Method and terminal according to claims 1 to11, characterized in that the source text of a given e-mailconverted into an XML structure [XMaiL] and the result according to RFC 2822is issued.
    [22]
    Verfahren und Endgerät nach den Ansprüchen 1 bis11, dadurch gekennzeichnet, dass eine gegebenen XML-Struktur [XMaiL]in den Quelltext einer E-Mail nach RFC 2822 umgewandelt und dasErgebnis ausgegeben wird.Method and terminal according to claims 1 to11, characterized in that a given XML structure [XMaiL]converted into the source code of an e-mail to RFC 2822 and theResult is output.
    [23]
    Verfahren und Endgerät nach den Ansprüchen 22und 21, dadurch gekennzeichnet, dass die Hintereinanderausführung derbeiden entgegengesetzten Umwandlungsschritte wieder das Ausgangsobjektliefert.Method and terminal according to claims 22and 21, characterized in that the successive execution of theboth opposite conversion steps again the starting objectsupplies.
    [24]
    Verfahren und Endgerät nach Anspruch 21, dadurchgekennzeichnet, dass das ausgegebene Ergebnis in einer XML-Datenbankgespeichert wird.Method and terminal according to claim 21, characterizedcharacterized in that the output result in an XML databaseis stored.
    [25]
    Verfahren und Endgerät nach Anspruch 22, dadurchgekennzeichnet, dass die Eingabe aus einer XML-Datenbank stammt.Method and terminal according to claim 22, characterizedcharacterized in that the input comes from an XML database.
    [26]
    Verfahren und Endgerät nach Anspruch 21, dadurchgekennzeichnet, dass die Eingabe aus dem Internet oder einem anderenNetzwerk, in dem RFC 2822-basierte E-Mails versendet werden, stammt,und das Ergebnis in ein Netzwerk weitergeleitet wird, in dem XML-Strukturen[XMaiL] verwendet werden.Method and terminal according to claim 21, characterizedmarked that input from the Internet or anotherNetwork where RFC 2822-based e-mail is sent,and the result is forwarded to a network in which XML structures[XMaiL] can be used.
    [27]
    Verfahren und Endgerät nach Anspruch 22, dadurchgekennzeichnet, dass die Eingabe aus einem Netzwerk stammt, in demXML-Strukturen [XMaiL] verwendet werden, und das Ergebnis in dasInternet oder ein anderes Netzwerk, in dem RFC 2822-basierte E-Mailsversendet werden, weitergeleitet wird.Method and terminal according to claim 22, characterizedin that the input is from a network in whichXML structures [XMaiL] are used, and the result in thatInternet or other network in which RFC 2822-based emailsbe sent, forwarded.
    [28]
    Verfahren und Endgerät nach den Ansprüchen 21bis 22 und 24 bis 27, dadurch gekennzeichnet, dass bei der UmwandlungSicherheitsmerkmale nach den Ansprüchen 12 bis 18 hinzugefügt oderentfernt werden.Method and terminal according to claims 21to 22 and 24 to 27, characterized in that in the conversionSecurity features added according to claims 12 to 18 orbe removed.
    [29]
    Verfahren und Endgerät nach den Ansprüchen 21bis 27, dadurch gekennzeichnet, dass das Gerät die zur Kommunikation nachdem SMTP-Protokoll (RFC2821) benötigtenInformationen aus dem <Header>-Element extrahierenund währendder Kommunikation im SMTP-Protokoll hinzugekommene Informationenim <Header>-Element einfügen kann.Method and terminal according to claims 21to 27, characterized in that the device according to the communicationneeded the SMTP protocol (RFC2821)Extract information from the <Header> elementand whilecommunication added in the SMTP protocolin the <Header> element.
    [30]
    Verfahren und Endgerät nach den Ansprüchen 1 bis18, dadurch gekennzeichnet, das das Endgerät sowohl E-Mails nach RFC 2822und den Folgestandards, als auch XML-Strukturen [XMaiL] verarbeitenund darstellen kann.Method and terminal according to claims 1 to18, characterized in that the terminal both emails according to RFC 2822and the following standards, as well as XML structures [XMaiL]and can represent.
    [31]
    Verfahren und Endgerät nach Anspruch 30, dadurchgekennzeichnet, dass dem <Header>-Element ein Attributhinzugefügtwird, mit dem seine Darstellung auf Endgeräten, die nur E-Mails nach RFC2822 und den Folgestandards darstellen können, nicht angezeigt wird.Method and terminal according to claim 30, characterizedcharacterized in that the <Header> element is an attributeaddedwill, with which its appearance on terminals, only e-mails to RFC2822 and the following standards can not be displayed.
    [32]
    Verfahren nach einem der vorangehenden Ansprüche, dadurchgekennzeichnet, dass zur Realisierung eine andere Datenstrukturals XML verwendet wird.Method according to one of the preceding claims, characterizedcharacterized in that for realizing a different data structureused as XML.
    类似技术:
    公开号 | 公开日 | 专利标题
    Gabriel et al.2017|Social Media
    US10185479B2|2019-01-22|Declassifying of suspicious messages
    Freed et al.1996|RFC2046: Multipurpose Internet Mail Extensions | Part Two: Media Types
    US7660989B2|2010-02-09|System for, and method of, authenticating an electronic message to a recipient
    DE60026244T2|2006-11-23|Thread-based email that sends a copy and server-specific distribution lists
    Gralla1998|How the Internet works
    DE69928277T2|2006-05-24|METHOD AND DEVICE FOR EXECUTING ERROR CORRECTION BY COMBINING TWO INSTRUMENTS OF A MESSAGE
    DE60103800T2|2005-07-14|Method for providing access to data
    Wahl et al.1997|Lightweight directory access protocol |: Attribute syntax definitions
    Moore1996|MIME | part three: Message header extensions for Non-ASCII text
    DE102007036647B4|2020-02-27|Method and device to facilitate the transmission of an encrypted roll code
    US6954934B2|2005-10-11|Management of links to data embedded in blocks of data
    KR101266086B1|2013-05-27|전자문서 유통 시스템
    US20190228467A1|2019-07-25|System for online lending services via an application service provider network
    US5710883A|1998-01-20|Hypertext document transport mechanism for firewall-compatible distributed world-wide web publishing
    US6643685B1|2003-11-04|Method of creating unique user aliases for users in a communications network
    DE69930504T2|2006-12-14|SYSTEM FOR TRANSMITTING ACCESS INFORMATION AND WEB CONTENT TO A MOBILE DEVICE
    KR100285122B1|2001-03-15|인터넷 전자우편 부가 서비스 시스템
    Elkins1996|MIME security with pretty good privacy |
    US6829635B1|2004-12-07|System and method of automatically generating the criteria to identify bulk electronic mail
    US5278955A|1994-01-11|Open systems mail handling capability in a multi-user environment
    US20050015626A1|2005-01-20|System and method for identifying and filtering junk e-mail messages or spam based on URL content
    US7831723B2|2010-11-09|Electronic document for describing a computer service
    US5884246A|1999-03-16|System and method for transparent translation of electronically transmitted messages
    DE60304100T2|2006-08-17|Enforcement of a time to disconnect a communication connection with cordless terminals with transient network addresses
    同族专利:
    公开号 | 公开日
    DE102004011042B4|2008-07-03|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    2005-09-29| OP8| Request for examination as to paragraph 44 patent law|
    2005-11-03| 8122| Nonbinding interest in granting licences declared|
    2008-03-27| 8181| Inventor (new situation)|Inventor name: INVENTOR IS APPLICANT |
    2009-01-02| 8364| No opposition during term of opposition|
    2020-10-01| R119| Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee|
    优先权:
    申请号 | 申请日 | 专利标题
    DE102004011042A|DE102004011042B4|2004-03-06|2004-03-06|Method and device for more efficient and secure encoding of e-mails|DE102004011042A| DE102004011042B4|2004-03-06|2004-03-06|Method and device for more efficient and secure encoding of e-mails|
    [返回顶部]